NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/misc-part1/9627

Internet Message Format | 1996-08-05 | 9.4 KB

Path: Chaos.es.co.nz!usenet
From: [e-mail] (NeuroMancer)
Newsgroups: comp.sys.amiga.misc
Subject: Re: Amiga Technology is insulting!!
Date: 25 Mar 1996 02:32:38 GMT
Organization: Efficient Software Internet Service
Message-ID: <[e-mail]>
References: <[e-mail]> <4is1sh$[e-mail]>
NNTP-Posting-Host: port0.nike.es.co.nz
X-Newsreader: THOR 2.22 (Amiga;TCP/IP) *UNREGISTERED*


Anders Karlsson, regarding your message ' Amiga Technology is insulting!!'  -

>In a message of 19 Mar 96 UNREGISTERED VERSION wrote to :

 UV>>    Except that AT just announced that they have cancelled all custom
 UV>> hardware architecture starting with the PPC "Amigas". The Amiga is now
 UV>> dead. A port of PPC AmigaDOS running on clones is all there is.

>Where did you hear this? Who said this? Because this is something
>that I belive you misunderstod. Amiga Tech. will NOT reinvent the
>weel by trying to build own custom chips. There already are chips
>that do all that stuff and is better at it.

>The Amiga will still be Amiga, because the thinking in the design
>of the hardware. Custom chips helping the processor.

>Your BS about Amiga becoming a clone (*bad* *word*) is just not
>true. If AT ports AmigaOS to other processors, great! Maybe that
>is something that will show PC-owners that M$ stinks..

I agree. Old 'UNREGISTERED VERSION' :-) seems to be living in the computing
industry of the '80's.

I say that Amiga Technologies forgoes making there own hardware to run
amigados, and instead makes it hardware independant. Like windoze NT, but
better.

You would be able to go and buy any motherboard (PC style for the
'economically malnurished' like me, or the 'gee whizz' multi-processor
hot-rods for the lucky buggers).

Such an amigados (since it would certainly require a re-write to be most
affective) would support not only RTG, retargetable sound, etc, but would
also have support for multiple processors, and idealy you would be able to
use any mix of cpu's at the same time. Possibly, the networking abilities
of a new amigados would extend beyond the normal, and allow networked
amigados machines to also share cpu load and facilities. It would also
recognise, and be able to use (with appropriate drives) PCI cards.

So, you could have amigados running on a pentium pro (yuk, but fast and
cheap) motherboard, and have it utilise a wide varitey of PCI cards, one of
which would be a gee-whizz svga card with built in 3d and mpeg chips for
$399 at your local no-brain pc box seller....


Now, if a suitably cunning plan was put into action, such an amigados would
also allow exclusive AND semi-exclusive access to any particular cpu. This
would be great for short-life software (games, demos, etc). The OS would
know what cpu's were available, of course... But it would also be possible,
in a multi-cpu enviroment, to have other os's running on specific cpu's
inside newAmigados at full speed. For instance, your system might have:

A pentium pro PCI motherboard + p6 cpu, ram, etc (price factor/availability)
1 gee-whizz SVGA card (with built in bells and whistles)
1 facncy-pants sound card (with accelerated bells and whistles)
1 CPU card with 2 PPC 601's, 16meg simm.

Now, along with the usual tasks, such a setup would allow you to emulate
both a mac and a pc at full speed. Perhaps more. The output would appear in
windows on the screen, or on there own screens (as the user configures).
The Emulated mac and pc would be tricked into thinking they were getting
i/o from there own exclusive devices. Simular to shapeshifter and pc-task,
but with no instruction translation needed.. Memory handling would be the
only real hold up, but given the local ram, and the speed of the pci bus,
and the ability to expand the local ram - I don't think it would be a great
problem... The cpu's would be running a multitasking kernal each, of which
the emulation would be one task.

Bang goes the compatibility barrier.

Bang goes the expensive custom hardware to run amigados barrier.

Bang goes problem of relying on outdated hardware.

Scalable.

Might cost a bit more than a PC on it's own - but, you are now driving a
ferrari, not a toyota...

In addition to amigados NT :-), AT might also make the odd PCI card. One
such card might contain the aga chipset - for use in cheap video/sound
work. Works best with Nu-AmigaDos, but there are drivers for windoze and
copland... It might have an '020 on the card as well; it might be AAA
instead of AGA...



On the bottom-most layer you have the multi-tasking micro-kernals which
are loaded from rom on the cpu cards; one kernal per cpu. They know about
communication with other cpu's; resource-tracking; multi-tasking (with
priorities); a module-compiler; and what the cpu has attached. There boot
sequence checks there hardware, and then meausres it's own performance.
Then the boot-cpu (the cpu which has the most ram and access to the HD)
proceeds to load the main OS off the hard disk. It then 'runs' it, which
consists of loading the first bit, 'compiling' the hardware independant
code into it's own specific machine code, and running it under the
micro-kernal it loaded off it's rom. Obviously, the now compiled and
running code instructs this cpu how to load the rest of the os - if it
didn't load it all then. I'll call that program the 'Boot Module'.

The boot module takes stock of what cpu's, etc are attached (by polling
them, and reading there 'info page'). Using this information, it loads and
delegates the various nu-amigados modules to the various cpu's, each of
which compiles it's module(s) and runs them. CPU-specific modules (those
ment for only one type of cpu, and without a compile stage) are given to
the appropritate cpu. At this stage, the boot-cpu is really just
co-ordinating the rest of them. After that, it may or may not discard the
boot-module, depending on how nu-amigados was written. Also, other I/O
devices (such as graphics and sound cards) are allocated to specific cpu's
- along with their device drivers, etc. at this time.

You can now load programs, which are treated in simular fashion to the os.
Programs are collections of modules, which contain code that needs to be
executed sequentially. The smaller the better. The 'Code' itself is perhaps
somthing like uncomiled assembler, but assembler for a virtual cpu that was
designed for speed and flexibility. It may or may not be based on a real
cpu. If it was based on the 68020 cpu, that may allow some backwards
compatibility. Comments ? Most code modules would spend there time waiting
for input from other modules, probably running on another cpu, in the form
an event message. They would be asleep during this time. Such a message
might contain parameters and/or data to be worked on. After the code module
processes it, the results are output to another module, and so on, until an
I/O device(s) get it. A program would consist of 1 or more code modules;
maybe hundreds.

CPU modules have their own ram, in the form of a simm socket or two. You
might have as little as 4 megs or as much as 16 megs or more on it. One of
the cpu modules has far more ram than the others. It acts as a communal
memory pool, where large datasets can be stored. It's cpu keeps it
co-herant, etc. If another cpu runs out of room for data in it's own local
ram, it may allocate some of the ram in the ram pool, and swap out an
amount of it's data to it, so it can work with the demands of the next
task. It swaps it back later. The ram pool might also be used to divide up
large datasets amoungst all the cpu's. IF a cpu ran out of room on it's
local ram to run CODE, it tries to find another cpu where the code will
fit. If it can't, and it's a high-priority task, it will then send a
message to the cpu which is running the lowest-priority task(s) to flush
them to the ram pool to make room for this task. If the ram pool has no
room, and virtual memory is allowed, the ram-pool cpu flushes tasks to
disk, starting at lowest priority. If that fails, program load is halted,
resources de-allocated, and the user informed. Programmers in the habit of
making large code modules would find life hard.

Compatibility with the old amigados binaries might be handled like other
emulations, but with help from other cpu's available since amigados is just
a bit more flexiable.

Bottlenecks would be kept to a minimum because of the message-passing
design of the os. Sending of large data packets would be minimal with well
written programs. Even so, PCI has a bandwidth like 130 megs/sec I
belive - so no big problem.

+ a whole bunch of other good ideas :-)

Changing hardware could be as simple as plugging your hard drives (and
controller + CPU module) into a new machine, or as complex as changing the
boot module on your hd AND moving your HD.


Well, thats another of my long-winded rants about the future design of
amigados. What do you and the others think of my big ideas ? :-)

...... Brendan

--
"Occasionally my Universe intersects with Reality"
                                 - Thompson the Great, c.1996
--
+-------------------------------------------------------------------+
|                               *NOTICE*                              |
|The contents of this message originating from Brendan Thompson are |
|     Copyright 1996 Brendan Thompson. All rights reserved.         |
|                                                                   |
| Permission is granted for organisations other than Microsoft to   |
|   reproduce all or part of this message, until further notice.    |
+-------------------------------------------------------------------+